1. Field of the Invention
The present invention relates to a mechanism usable for controlling a call management for a subscriber call. In particular, the present invention relates to a method of controlling a call management of a subscriber call, a corresponding system, a corresponding network control element and a corresponding computer program product which are usable for a service configuration, such as a supplementary service configuration, within a call continuity environment, e.g. a voice call continuity architecture.
For the purpose of the present invention to be described herein below, it should be noted that                a communication equipment or subscriber terminal may for example be any device by means of which a user may access a communication network; this implies mobile as well as non-mobile devices and networks, independent of the technology platform on which they are based; only as an example, it is noted that communication equipments operated according to principles standardized by the 3rd Generation Partnership Project 3GPP and known for example as UMTS terminals are particularly suitable for being used in connection with the present invention;        although reference was made herein before to voice call, this exemplifies only a specific example of content; content as used in the present invention is intended to mean also multimedia data of at least one of audio data, video data, image data, text data, and meta data descriptive of attributes of the audio, video, image and/or text data, any combination thereof or even, alternatively or additionally, other data such as, as a further example, program code of an application program to be accessed/downloaded;        method steps likely to be implemented as software code portions and being run using a processor at one of the entities described herein below are software code independent and can be specified using any known or future developed programming language;        method steps and/or devices likely to be implemented as hardware components at one of the entities are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS, CMOS, BiCMOS, ECL, TTL, etc, using for example ASIC components or DSP components, as an example;        generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the present invention;        devices or means can be implemented as individual devices or means, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved.        
2. Related Prior Art
In the last years, an increasingly extension of communication networks, e.g. of wire based communication networks, such as the Integrated Services Digital Network (ISDN), or wireless communication networks, such as the cdma2000 (code division multiple access) system, cellular 3rd generation (3G) communication networks like the Universal Mobile Telecommunications System (UMTS), cellular 2nd generation (2G) communication networks like the Global System for Mobile communications (GSM), the General Packet Radio System (GPRS), the Enhanced Data Rates for Global Evolutions (EDGE), or other wireless communication system, such as the Wireless Local Area Network (WLAN), took place all over the world. Various organizations, such as the 3rd Generation Partnership Project (3GPP), the International Telecommunication Union (ITU), 3rd Generation Partnership Project 2 (3GPP2), Internet Engineering Task Force (IETF), and the like are working on standards for telecommunication network and multiple access environments.
In general, the system structure of a communication network is such that one party, e.g. a subscriber's communication equipment, such as a mobile station, a mobile phone, a fixed phone, a personal computer (PC), a laptop, a personal digital assistant (PDA) or the like, is connected via transceivers and interfaces, such as an air interface, a wired interface or the like, to an access network subsystem. The access network subsystem controls the communication connection to and from the communication equipment and is connected via an interface to a corresponding core or backbone network subsystem. The core (or backbone) network subsystem switches the data transmitted via the communication connection to a destination party, such as another communication equipment, a service provider (server/proxy), or another communication network. It is to be noted that the core network subsystem may be connected to a plurality of access network subsystems. Depending on the used communication network, the actual network structure may vary, as known for those skilled in the art and defined in respective specifications, for example, for UMTS, GSM and the like.
Generally, for properly establishing and handling a communication connection between network elements such as the communication equipment (or subscriber terminal) and another communication equipment or terminal, a database, a server, etc., one or more intermediate network elements such as network control elements, support nodes or service nodes are involved. Network control elements, such as a Mobile Switching Center (MSC) or the like, are responsible for controlling the call establishment, call control, call termination, and the like.
Since more and more communication network systems, such as circuit switched (CS) networks, packet switched (PS) networks, Internet Protocol (IP) based networks, for example IP Multimedia Subsystem (IMS), and the like are established in parallel, the provision of an interconnection between these network systems for enabling the continuation of calls of a subscriber gets an increased relevance. For this purpose, call continuity solutions are developed, which are also called voice call continuity (VCC), by means of which a call, for example a voice call, can be continued even if the subscriber is moving between different communication network systems, such as between cellular (e.g. circuit switched) networks and IP based networks (e.g. Wireless Local Area Network (WLAN), wherein the enablement of routing of the call to the respective proper domain (for example circuit switched domain or IP domain, such as an IMS domain) is to be ensured.
In 3GPP, the usage of Voice Call Continuity (VCC) is under investigation. There are prepared mechanisms and corresponding specifications for enabling the routing of a voice call to a proper domain (CS or IMS), a handover between domains (CS and IMS) as well as supplementary service end-user-experience when a subscriber uses either of these domains.
In the specification 3GPP TR 23.806 (V 7.0.0) there are proposed different architectural models in order to fulfil the requirements for providing the VCC function. One of these models is the so called IMS controlled static model where all calls are routed via the IMS domain in order to anchor the connection for a possible handover scenario.
An example for a system structure involving a VCC architecture is shown in FIG. 4. As shown in FIG. 4, one alternative for the VCC between, for example, a circuit switched network domain and an IMS network domain is to route all calls via a Media Gateway Control Function (MGCF) and an IMS-Media Gateway (MGW). This alternative is presented in the specification 3GPP TR 23.806 (V 7.0.0). In FIG. 4 reference sign 1 denotes a dual mode user equipment which is able to communicate with different networks, such as cellular circuit switched networks and IP based networks like an IMS; reference sign 2 denotes an access network subsystem for a circuit switched network domain 20, for example a GSM EDGE (Enhanced Data Rates for GSM) radio access network (GERAN) and/or UMTS radio access network (UTRAN), providing access for a connection of the subscriber to the CS network domain 20; reference sign 3 denotes a MSC for controlling communication connections in the CS network 20; reference sign 4 denotes a Gateway-MSC (GMSC) which provides a connection to other networks, such as a Public Switched Telecommunication Network (PSTN) 40. Reference sign 5 denotes a gsmSCF (GSM-Service Control Function) defining the IN (Intelligent Network) control environment for a mobile network such as the CS network 20, wherein the gsmSCF is adapted to enable an interworking with GSM/GPRS systems. On the other hand, in FIG. 4, reference sign 6 denotes an IP Connectivity Access Network (IP CAN) defining an access network connecting an IMS subscriber to IMS services, i.e. to an IMS network domain 30; reference sign 7 denotes a Call State Control Function (CSCF) of the IMS for processing signalling and performing session control in the IMS network 30, which may comprise a Proxy-CSCF, an Interrogating-CSCF and/or a Serving-CSCF; reference sign 8 denotes a Call Continuity Control Function (CCCF) for providing functions for call continuity between the GSM/UMTS circuit switched domain and IMS domain using an IP CAN; reference sign 9 denotes a Media Gateway Control Function (MGCF) being a central node of a PSTN/CS gateway and converting protocols; reference sign 10 denotes a Media Gateway providing an interface for the media plane of the PSTN 40 or the CS network 20; reference sign 11 denotes a Home Subscriber Server (HSS) providing database functions that are required in network, such as HLR (Home Location Register) functions, DNS (Domain Name Servers) functions, and security and network access databases; reference sign 12 denotes a Network Domain Selection (NeDS) representing a control point for selecting which domain to use for terminating a call. The control plane interconnections between the various network elements according to FIG. 4 are illustrated by solid lines while the user plane interconnections, such as speech path, for a respective communication connection are illustrated by dashed lines. The general functions and the processing of a call in such a network system is known to those skilled in the art so that further detailed explanations are omitted herein.
With regard to the VCC functionality in the architecture according to FIG. 4, the main network elements specific for this continuity function are the dual mode UE 1, the CCCF 8 and the NeDS 12. All VCC transitions (i.e. initial and subsequent) associated with a particular user session are executed and controlled by the CCCF 8 upon UE's request. The CCCF 8 provides in particular the following functions for call continuity: reception and processing of call continuity requests caused by radio related events, e.g. availability or loss of radio coverage, and establishment, catenation and release of call legs needed to transfer a voice call from CS domain to IMS domain, or visa versa. The NeDS 12 functions as the control point for selecting which domain is to be used for terminating a call. Normally it may be expected that a CS terminating call will terminate on the CS side of a multi-mode terminal, and an IMS terminating call will terminate on the IMS side of a multi-mode terminal. However, there are situations where the selection of the other domain is appropriate (e.g. in the case of a CS terminating call when the terminal is not CS-attached, but is IMS registered). In addition to technical considerations, user preferences and service availability considerations may be considered and are implemented in the NeDS function. The NeDS function is specified by the following:                The NeDS function is aware of whether the terminal is registered on IMS from a device that is Multimedia telephony (with IMS voice) capable, and on an access that is capable to support IMS voice;        The NeDS function is aware of whether the terminal is attached to the CS domain.        The NeDS function is aware of or can obtain the ongoing voice call in the IMS and the CS domain.        The NeDS function controls the decision as to the appropriate terminating domain, taking into account the operator, user and service preferences.        
Based on the architecture according to FIG. 4, there has been developed a further alternative for a network architecture involving VCC wherein a so called Access Gateway Control Function (AGCF) is introduced and associated into a (visited) MSC for subscribers having the capability to move between IMS and CS domain. This kind of architecture is shown in FIG. 5.
In FIG. 5, the network elements being equivalent to those shown in FIG. 4 are denoted by the same reference signs, and a further definition thereof is omitted. In addition to these network elements, there are illustrated in FIG. 5 additional access networks including a Unlicensed Mobile Access Network (UMAN) 21 and an Industrial Wireless Local Area Network (I-WLAN) 22 comprising an Wi-Fi interoperability portion 23, by means of which a subscriber terminal (not shown) may access the network. The UMAN is connectable to the MSC 3 (CS network) by means of, for example, a air interface. It is to be noted that the MSC 3 may also comprise a MSC server (MSS). The I-WLAN 23/Wi-Fi 23 is connectable to the IP CAN 6 by using, for example, a Session Initiation Protocol (SIP) based connection. Furthermore, as shown in FIG. 5, there are provided several CSCFs for different function, i.e. a Proxy-CSCF (P-CSCF) 33 for connection to the IP CAN 6, a P-CSCF 32 for connection to the CS network, and a Serving CSCF (S-CSCF) 34 with which the P-CSCFs 32, 33 are connected. The connection type to and from the P-CSCFs 32, 33 and to the S-CSCF 34 are SIP based connections, for example. Furthermore, in the IMS domain, so-called Application Servers (AS) 35 are provided (only one is shown in FIG. 5) which are SIP entities that host and execute services. For example, in the presented case, the AS 35 is both responsible of voice call continuity functions as well as supplementary services. The S-CSCF 34 and the AS 35 are connected via an IP multimedia subsystem Service Control Interface (ISC) based on SIP. It is to be noted that the same interface type ISC/SIP is used for connecting the S-CSCF 34 and the CCCF 8. Furthermore, the S-CSCF 34 is connected to the HSS 11 by means of a Cs/Dx interface. On the other hand, as indicated before, the MSC 3 on the CS network side is associated with the AGCF 31 being connectable to the P-CSCF 32 via a SIP based connection.
It is to be noted that even though in FIG. 5 the AGCF 31 is shown as being associated with the MSC, the ACGF may be combined with the P-CSCF in one entity. In such a case, there would be a communication between the MSC and the ACGF/P-CSCF entity. Which structure is chosen is to be decided by the network provider. As a further alternative, the AGCF may also be provided as a single external element with corresponding connections to the network, such as to MSC and/or P-CSCF.
In the structure shown in FIG. 5, the main elements to be considered for the voice call continuity function are the CCCF 8, as described in FIG. 4, and the AGCF 31 (irrespective of whether the AGCF is comprised in MSC, P-CSCF or provided as separate external element). The AGCF 31 may be configured to actually representing a 3GPP-compliant SIP User Agent (UA) towards IMS. Furthermore, the AGCF may behave as a user equipment towards the IMS network for calls connected via the CS domain. It may perform registration and session establishments as defined, for example, by the 3GPP TS 23.806 (V 7.0.0). When the subscriber makes a location update to the CS domain (i.e. to the visited MSC 3), then the AGCF 31 initiates a 3GPP defined SIP registration towards the S-CSCF 34 located in IMS via the connection through the P-CSCF 32. Eventually when calls are made by a subscriber having a VCC compliant phone and represented by the AGCF 31 towards the IMS as a 3GPP compliant SIP UA, then those calls can be routed directly from the AGCF 31 into the IMS domain as voice over IP (VOIP) calls. Similarly in this architecture calls terminating to a particular subscriber are routed via the IMS domain to the AGCF 31. On the other hand, in case the subscriber terminal is not VCC capable, the call is routed to the PSTN (or PLMN (Public Land Mobile Network)) 40.
In current 3GPP specifications (e.g. Release 5 or 6), it is not defined how voice call related supplementary services are defined. Therefore, it is started to specify, for example in TISPAN (Telecoms & Internet converged Service & Protocols for Advanced Networks), how an IMS architecture is to be changed in order to support supplementary services as those existing today within fixed or mobile CS networks. In detail, it is in particular investigated how a service will work in overall within IMS and by using SIP.
As one item, it is to be defined how a subscriber's terminals using extendible Mark-up Language (XML) can modify settings for supplementary services based thereon. Preferably, all supplementary services such as Call Forwarding services have an own individual set of parameters such as state (active, inactive, etc.) of individual call forwarding service, address of forwarded-to-subscriber (in Universal Resource Identifier, URI) etc. In this connection, one possible way is that the functionality of service will follow the way in which the services are implemented presently within CS networks, which is known to those skilled in the art and therefore not explained in detail herein.
However, the problem is in which way a subscriber is able to modify XML documents that exists within the network. There exists a so-called XCAP (XML Configuration Access Protocol) mechanism which is used to transfer XML documents over HTTP/TCP/IP between terminal endpoints and server(s) located within the core network. This is illustrated in FIG. 6. A corresponding mechanism is applied, for example, for OMA (Open Mobile Alliance) Push-to-Talk within 3GPP to modify group list. When a subscriber terminal 70 uses a XCAP connectivity towards the core network, it will indicate the particular document it will modify. In addition to this, the terminal will also indicate which particular element within the XML document will be modified and with what content. According to FIG. 6, the subscriber terminal sends a corresponding indication to a XML document storage server 71 located in the core network, in which the modification of the XML document takes place. The indication is sent, for example, by means of a Active_CFU (Call Forwarding Unconditional) message including a C-number. After the notification, the XML document storage server 71 initiates a notification about the modification via a SIP connection to a respective application server 72 which is interested of the information, for example a application server providing the respective service. It is to be noted that the XCAP interface is also called Ut-interface in 3GPP IMS specifications (e.g. in connection with conferencing or OMA PoC (Push to talk over Cellular applications).
However, in network system providing a call continuity function, in particular a VCC architecture, an end user is not able to modify data portions, such as XML documents, representing the service if there is no IP-layer connectivity between end user terminal and the server that holds the documents. In particular, in case the terminal is not supporting the XCAP but still uses supplementary service functionalities as defined by TISPAN, when for example the IMS controlled model is used and calls are routed via IMS and application servers (both responsible of voice call continuity as well as supplementary services), the user has no access to a service configuration or call management or the like.